home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by Christian Huitema/INRIA
-
- Minutes of the Simple Internet Protocol Working Group (SIP)
-
- The SIP Working Group met Tuesday morning and Wednesday afternoon. The
- Tuesday session was devoted to the finalization of the SIP
- specification, specially in light of the first interoperability
- experiences. The Wednesday session was devoted to the analysis of
- routing protocols.
-
- SIP Specification
-
- The first speaker in the session was Steve Deering, who reviewed the
- recent ``precisions'' to the SIP specification:
-
-
- o The first 32 flow-ids values have been ``reserved'' for IP ``TOS''
- compatibility.
-
- o The formats for the LSR and reassembly payloads has been slightly
- modified, so that the ``payload type'' arrives first.
-
- o The payload type 0 has been reserved for hop by hop options.
- Routers are supposed to inspect the payload type of every packets.
- If this type is set to zero, then ``hop by hop'' options should be
- examined.
-
-
- A generic format for hop by hop has been defined: after a generic
- ``option header'' expressing the embedded payload type and the number of
- 64 bit words used to carry the option, each hop by hop option is
- represented by a set of 32 bit words; the first octets include the
- option type and the option length, expressed as a number of 32 bit
- words. There was a discussion on the adequacy of using the 32 bit words
- units, and a proposal to use a byte count instead; the Working Group
- turned this down, and reached consensus on 32 bit word count. Steve
- then presented the requirements for ``option ordering''. To sum up, it
- is required to have the following order in the packets:
-
-
- o Sip header
- o Hop by hop option, if present
- o Source route option, if present
- o Fragmentation header, if present
- o Data
-
-
- Then, Steve presented a change in terminology: ``Cluster address''
- instead of ``anyone'' address. The Working Group noted the requirement
- for two precisions in the specifications:
-
- 1
-
-
-
-
-
- 1. Multicast addresses cannot be used in source routes.
- 2. Cluster addresses should never be used as source addresses. This
- implies that cluster addresses should not be used for TCP
- connections, as they cannot be used as ``reply'' addresses.
-
-
- Steve also mentioned that the new specification will include precisions
- on the ``pseudo checksum computation'' (e.g., for ICMP and IGMP), in
- particular when the ``C'' bit is set.
-
- IEEE-802 Address Format
-
- The discussion switched then to the definition of an IEEE-802 address
- format. Steve Deering and Bob Hinden presented a format where a SIP
- address can be build by prepending a 16 bit header to an IEEE-802 48 bit
- address.
-
-
- ------------------------------------
- | prfx | Subnet | IEEE-802 address |
- ------------------------------------
-
-
- The 16 bit prefix, in this proposition, is divided in two fields, a 6
- bit prefix for recognizing this address as an IEEE-802 address, and a 10
- bit ``subnet identifier'' to identify the ``local network'' to which the
- station is connected. This triggered a discussion on the usage of this
- addresses and the proper length for the prefix and subnet field, with
- the following conclusions:
-
-
- o These addresses should only be used as long as no ``real SIP''
- address has been assigned to the station.
- o They should never be advertized outside of the ``autonomous
- system'', i.e. through IDRP.
- o The prefix should be 8 bit long, and the subnet also 8 bit. The
- need to study the interaction with the DNS was also mentioned.
-
-
- Security Labelling
-
- The last speaker in Tuesday's session was Randy Atkinson, who had
- submitted a ``SIPSO'' draft, describing a ``security labeling'' option,
- and also presented the various possibilities for designing an end-to-end
- security option based on SP-3 and NLSP. The discussion of the labeling
- option was marked by the following comments:
-
-
- o The main rationale for the labeling proposal was ``compatibility
- with IPv4''. Some IPv4 routers used in ``secure environment'' use
-
-
- 2
-
-
-
-
-
- the labeling service, and would suffer from ``reduced
- capabilities'' if the function was not available.
-
- o It was pointed out that security label alone were not very useful
- and that security should be addressed ``globally'', e.g. also in
- the routing architecture.
-
- o Randy Atkinson mentioned that one rationale for the labeling option
- was also to prevent negative feelings, e.g. propagation of the
- false impression that SIP would be more ``insecure'' than IPv4
- because it would be missing the option.
-
-
- In fact, all members agreed that end-to-end security was much more
- important. Randy continued his presentation by explaining how SP-3 is
- used to encapsulate and protect IP packets. It was decided to track the
- IPv4 efforts on the subject, and to come out with a SIP version of their
- proposal as soon as the IPv4 drafts stabilize.
-
- Session 2
-
- The first point on the Agenda of the Wednesday session was the review of
- the ``DNS for SIP'' draft. The draft defines an ``AA'' type record for
- storing the 64 bit SIP addresses, and a reverse tree under
- ``sip-addr.arpa''. It was decided after discussions to align the format
- of the reverse addresses with the ``standard'' external format of SIP
- addresses. The name corresponding to the SIP address:
-
-
- 0abc:f120:138.96.24.84
-
-
- will be obtained through the inverse domain name:
-
-
- 84.24.96.138.f120.abc.sip-addr.arpa
-
-
- The SIP-DNS Draft will be updated accordingly.
-
- SIP Version of Three Routing Protocols
-
- The next part of the session was devoted to the study of the ``SIP''
- version of three routing protocols, RIP, OSPF and IDRP.
-
-
- o The SIP-RIP draft was presented by Gary Malkin. The draft is
- derived from RIP-2, with the following modifications:
-
- - Addresses are 64 bit,
-
- 3
-
-
-
-
-
- - Bit masks are contiguous,
- - The metric is designed to converge on the best throughput,
- instead of the lesser number of hops.
-
- Gary presented then three possible amendments to SIP-RIP, proposed
- by himself and Yakov Rekhter:
-
- 1. As the SIP routers can easily now the MTU ofterface on which a
- RIP packet is transmitted, there is no need for a standard 576
- length limit -- they can as well make packets as big as the MTU
- allows.
- 2. By using an algorithm suggested by () and by () in the 1989
- SIGCOM conference, it is possible to remove the ``bouncing
- effect'' and to compute loop free routes. The cost is to add
- one extra address information per routing entry, and one
- computation step before propagating routes.
- 3. By using the ``route on demand'' improvement suggested in a
- draft by ??
-
- After discussion, it was decided that modification (1) and (2)
- should be incorporated in the current draft, and that (3), which
- represent a substantial although compatible improvement, should be
- specified in a separate document.
-
- o The SIP-OSPF Draft was presented by Christian Huitema. The main
- features of the Draft are:
-
- - Regular OSPF, running over IPv4
- - Two additional LSAs to import SIP information and an additional
- bit in the router-LSA to indicate SIP capability.
- - ``Integrated routing'' in order to ease the migration from IPv4
- to SIP, after which a native OSPF for SIP would be defined.
-
- A number of points were raised:
-
- - The IPv4 address to use when tunneling should be that of the
- selected interface to the dual SIP/IPv4 host. There should be
- a way to identify this interface address.
- - The translation between SIP and IPv4 formats should only take
- place in border routers.
- - We should avoid doing ``double transition''. The specification
- should be definitive.
- - We should specify clearly whether ``SIP'' areas are requested
- to have the same boundaries as ``IPv4'' areas.
- - When defining new LSAs, we should perhaps be able to specify a
- ``multiprotocol'' format.
-
-
-
- 4
-
-
-
-
-
- It was decided that all detailed discussions of OSPF in SIP would
- be carried on in the SIP Working Group.
-
- o The IDRP for SIP draft written by Sue Hares was presented by Yakov
- Rekhter. Options for representing SIP addresses and for
- identifying SIP ``autonomous systems'' were discussed, as well as
- the need to define a document for multicast routing.
-
-
- Bill Simpson presented the provisional results of the working party on
- ES/IS, ARP and autoconfiguration.
-
- Attendees
-
- Kannan Alagappan kannan@dsmail.lkg.dec.com
- Guy Almes almes@ans.net
- Michael Anello mike@xlnt.com
- Randall Atkinson atkinson@itd.nrl.navy.mil
- David Battle battle@cs.utk.edu
- Tom Benkart teb@acc.com
- Fred Bohle fab@interlink.com
- David Bolen db3l@ans.net
- Erik-Jan Bos erik-jan.bos@surfnet.nl
- Robert Braden braden@isi.edu
- Monroe Bridges monroe@cup.hp.com
- David Bridgham dab@epilogue.com
- Al Broscius broscius@bellcore.com
- Jeff Carman tcarman@bnr.ca
- Kevin Carosso kvc@innosoft.com
- David Carr Carr@acsu.buffalo.edu
- John Chang jrc@uswest.com
- Rob Coltun rcoltun@ni.umd.edu
- Steve Deering deering@parc.xerox.com
- Osmund DeSouza osmund.desouza@att.com
- Chas DiFatta chas@cmu.edu
- Ralph Droms droms@bucknell.edu
- David Dubois dad@pacersoft.com
- Pierre Dupont dupont@mdd.comm.mot.com
- Tom Easterday tom@cic.net
- Dino Farinacci dino@cisco.com
- Dennis Ferguson dennis@ans.net
- Eric Fleischman ericf@act.boeing.com
- Paul Francis Francis@thumper.bellcore.com
- Peter Furniss p.furniss@ulcc.ac.uk
- John Gawf gawf@compatible.com
- Joseph Godsil jgodsil@ncsa.uiuc.edu
- Ramesh Govindan rxg@thumper.bellcore.com
- Danny Hanson hanson.tic@commlan.safb.af.mil
- John Hascall john@iastate.edu
- Robert Hinden hinden@eng.sun.com
- Jeffrey Honig Jeffrey_C_Honig@Cornell.edu
- Steven Hubert hubert@cac.washington.edu
- Christian Huitema christian.huitema@sophia.inria.fr
-
- 5
-
-
-
-
-
- John Ioannidis ji@cs.columbia.edu
- Phil Irey pirey@relay.nswc.navy.mil
- Ronald Jacoby rj@sgi.com
- David Johnson dbj@cs.cmu.edu
- Laurent Joncheray lpj@merit.edu
- Dan Jordt danj@nwnet.net
- Doug Karl dkarl@osu.edu
- Kenneth Key key@cs.utk.edu
- Charley Kline cvk@uiuc.edu
- Moshe Kochinski moshek@FibHaifa.com
- Mark Laubach laubach@hpl.hp.com
- Mark Lewis Mark.S.Lewis@telebit.com
- Yu-Lin Lu yulin@hpinddu.cup.hp.com
- Paul Lustgraaf grpjl@iastate.edu
- Charles Lynn clynn@bbn.com
- Bruce Mackey brucem@cinops.xerox.com
- Carl Madison carl@startek.com
- Gary Malkin gmalkin@xylogics.com
- David Meyer meyer@ns.uoregon.edu
- Greg Minshall minshall@wc.novell.com
- Matthew Morrisey morrisey@wpsp01.hq.aflc.af.mil
- John Moy jmoy@proteon.com
- Erik Nordmark nordmark@eng.sun.com
- William Owens owens@acsu.buffalo.edu
- Michael Patton map@bbn.com
- Gaige Paulsen gaige@intercon.com
- John Penners jpenners@advtech.uswest.com
- Willi Porten porten@gmd.de
- David Reese dave@csu.net
- Yakov Rekhter yakov@watson.ibm.com
- Manoel Rodrigues manoel_rodrigues@att.com
- Yzhak Ronen y.ronen@homxa.att.com
- William Simpson Bill.Simpson@um.cc.umich.edu
- Subbu Subramaniam subbu@cup.hp.com
- Terry Sullivan terrys@newbridge.com
- Fumio Teraoka tera@csl.sony.co.jp
- Kamlesh Tewani ktt@arch2.att.com
- Richard Thomas rjthomas@bnr.ca
- Susan Thomson set@bellcore.com
- L. Stuart Vance vance@tgv.com
- John Veizades veizades@apple.com
- Dinesh Verma verma@watson.ibm.com
- Warren Vik wmv@lachman.com
- Ruediger Volk rv@informatik.uni-dortmund.de
- Chuck Warlick warlick@theophilis.nsfc.nasa.gov
- Scott Wasson sgwasson@eng.xyplex.com
- Von Welch vwelch@ncsa.uiuc.edu
- Fred Whiteside fred@bws.com
- Steven Willis steve@wellfleet.com
- Richard Woundy rwoundy@vnet.ibm.com
- Charles Young Charles.E.Young@att.com
-
-
-
- 6
-